home *** CD-ROM | disk | FTP | other *** search
/ Pascal Super Library / Pascal Super Library (CW International)(1997).bin / LIBRARY / PBLIB1 / DOC / MYOBJS.DOC < prev    next >
Encoding:
Text File  |  1994-04-30  |  11.2 KB  |  279 lines
  1. \space 20
  2. \CENTER on
  3. Howard's OBJECTS
  4.  
  5. \space 20
  6.  
  7. \CENTER off
  8. \indent 30
  9. \source howard.adr
  10. \indent 0
  11. \new
  12. \CENTER Introduction
  13. \join on
  14.  
  15.      I am a medium old-fashioned programmer.  I started 25 years ago,
  16. and programmed for a living on more systems and in more languages than I
  17. like to remember.  I learned not to use GOTOs, but somewhere in the 80s
  18. I stopped getting excited about new programming techniques and concentrated
  19. on simply making things that worked.
  20.  
  21.      Turbo Pascal is the best all-around language I have ever used.  When
  22. they introduced Units, it really marked the end of the monolithic program,
  23. and made it practical to re-use code.  The concept of Objects leaped beyond
  24. units, but somewhere around "virtual methods" it lost me.
  25.  
  26.      My use of objects is both primitive and extremely useful.  I focus
  27. on the ability of an object to encapsulate code and data, making complex
  28. functions appear to be simple.  One of the things that was always difficult
  29. prior to objects, was coding the second instance of whatever.  It was
  30. straight-forward to code, say, the first use of a .dbf file in your
  31. program, but adding a second always involved global variables which had
  32. to be used simultaneously to track two different things.  Making the code
  33. into an object allowed simultaneous use almost trivially.
  34.  
  35.      An object is also the best place to hide truely ugly code.  We all
  36. have it.  There are things that simply need to be done quickly, with
  37. cleanup later (hopefully).   I hope that the ugliest of the code is
  38. gone before I release these objects and utilities for the first time,
  39. but if not, I apologize in advance.
  40.  
  41.  
  42. \new
  43. \CENTER Personal Bias
  44.  
  45.      Code is personal, and reflects the biases of the author.  I have
  46. a few, and I will try to explain them.
  47.  
  48. \join off
  49.  
  50. 1. Efficient code is nice, but not terribly important.  I try not to
  51.      waste CPU cycles, but hardware gets better by a factor of 2 each
  52.      year, and I improve by maybe 10%.  The choice is obvious.
  53.  
  54. 2. Code size and EXE size is a little more important, but again, not
  55.      critical.  With all the configuration and output support routines,
  56.      my "Hello world." size is around 15k.  A seriously useful utility
  57.      can be written in 100 lines or so of non-library code and take
  58.      >25k.  To me, this is good.  I have done what I can to keep the
  59.      size down, but I think the situation is about optimum now.  I welcome
  60.      improvements down at the lowest level because they give the
  61.      greatest returns, but thorough testing is in order.
  62.  
  63. 3. I use minimum comments in the code.  My preference is to name
  64.      routines and variables sensibly, and only document the subtle
  65.      points.  Comments on code lines tend to hide structure.
  66.  
  67. 4. My development system is a 486DX2-66, 16Mb ram, 450Mb disk and
  68.      LaserJet IV printer.  I have access to smaller systems, but my
  69.      smallest is a 386-40.  Obviously, this affects my code.  Most
  70.      specifically are instances of sending LJ escape sequences to
  71.      the printer.  I hope to cut out and make optional, all printer
  72.      specific strings, but the first release may still have some.
  73.  
  74. \new
  75. \center 'On To Objects'
  76. \join off
  77.  
  78. The Objects which I use most are as follows:
  79.  
  80. 1. STR_object - consists of a Pascal string (1-255 chars) allocated
  81.             from the Heap.  Can be stored or fetched.  Not too exciting.
  82.  
  83. 2. STRA_object   - an array of STR_objects, with the strings and pointers
  84.             all on the Heap.  This feels a lot like a text file in memory.
  85.             Can store and fetch randomly or sequentially. Can be searched
  86.             and sorted.  Useful as a memory image of a text file or a
  87.             list of things like file names.  Can be saved to disk or loaded
  88.             from disk.  Looks like:
  89.  
  90.                 Index      STRING
  91.                   1        xxxxxxxxx
  92.                   2        yyyyy
  93.                   3        zzzzz
  94.                   ...
  95.  
  96.              I have not fully examined the limits.  I suspect either the
  97.              index or the strings or something is limited to 64k.  I have
  98.              chosen 10,000 as a compiled in limit.  When initting the object
  99.              an actual allocation limit less than that is chosen for each
  100.              instance.  I have loaded a 173,900 byte text file (3674 lines)
  101.              into a STRA.  It used slightly over 200kbytes of heap when the
  102.              initialization was set to 3700.  Empty array initialization
  103.              averages 12 bytes per string, but some is recovered in use.
  104.              All-in-all, this is an extremely useful construct, especially
  105.              in some of its descendant forms.
  106.  
  107. 3. HOLD_object   - descendent of STRA_object.  Adds and array of longints
  108.             which travel with each string.
  109.  
  110.                 Index      STRING       NUM
  111.                   1        xxxxxxxxx    123456
  112.                   2        yyyyy             1
  113.                   3        zzzzz        999999
  114.                   ...
  115.  
  116.              If the string array is sorted, the num value moves along with
  117.              it, making the list good for things like pointers to sections
  118.              in a text file (HELP_object, SORTSECT).
  119.  
  120. 4. FILE_object   - an encapsulation of the binary file I/O, blockread,
  121.              blockwrite code.  I haven't used this too much.
  122.  
  123. 5. TFILE_object  - an encapsulation of TEXT file I/O.  This is central
  124.              to virtually every program I write.  I find it much more
  125.              friendly than straight Pascal code.  Important here is the
  126.              implementation of some PD code for random access - TEXTSEEK.
  127.  
  128. 6. OUT_object    - I have been aiming towards this for years.  I wanted:
  129.              1. Hide the bookkeeping for list output, headers, footers
  130.                   line numbers, page numbers.
  131.              2. Have a program be able to interchangeably, but intelligently
  132.                   switch between output to the CRT, PRINTER or a TEXT file.
  133.                   This is things like pausing when output is to the
  134.                   CRT, form feeds to the printer, and saving output to
  135.                   text files.
  136.              3. Control these options with run time parameters, and hide
  137.                   virtually all of it from the program which uses it.
  138.  
  139.              After constructing the OUT_object, I found that it added
  140.              8k or so to even very simple programs which didn't need
  141.              all the frills.  I then divided it into two levels, 0 & 1
  142.              and hid this further into two libraries OUTLIB0 and OUTLIB1.
  143.              The level 0 object only adds about 4k per program.  So a
  144.              program can start with outlib0 (no headers, footers and
  145.              word-wrap), and by changing to uses outlib1, can trivially
  146.              add the headers etc.
  147.  
  148.  
  149. 7. HELP_object   - Needs a better name, but I wrote it to implement HELP
  150.              files.  This is basicly a text file with random access to
  151.              sections of the file.  The sections can be pretty flexibly
  152.              designated, some constant string at the beginning of the
  153.              line followed by a name string.
  154.  
  155.  
  156. 8. DBF_object    - Not quite ready for publication.  Started out with a
  157.              bit of PD code for reading DBF files (Gerald Rohr).  Worked
  158.              out most of header, and file structure and encapsulated as
  159.              DBF_object.  Couldn't make heads nor tails of .NDX files, so
  160.              I used a string array descendent (STRX) to make indexing
  161.              easy.  KEYED_DBF_object handles multiple key files and multiple
  162.              and partial key fields.  I used this as the basis for a group
  163.              of utilites consolidated into DB.exe to DUMP, CLONE, SORT
  164.              EXPORT, CREATE, and DDL(show structure).  A few small missing
  165.              pieces yet.
  166.  
  167. 9. BITMAP_object  - I haven't used this in a couple of years.  It was
  168.              a large virtual bit-map, using heap in memory and loadable
  169.              and saveable to disk.
  170.  
  171. \NEW
  172. \CENTER STR_object - 1. String on Heap - Detail
  173.  
  174. Here is the interface to the STR_object:
  175.  
  176. {source \hnrlib\hnrobjs.pas(.str_object)}
  177. \source \hnrlib\hnrobjs.pas(.str_object)
  178.  
  179. The data for the object consists of a pointer to a string on the heap.
  180.  
  181. \NEW
  182. \CENTER STRA_object - 2. String Array - Detail
  183.  
  184. Here is the interface to the STRA_object:
  185.  
  186. {source \hnrlib\hnrobjs.pas(.STRA_object)}
  187. \source \hnrlib\hnrobjs.pas(.STRA_object)
  188. \join
  189.  
  190.      As you can see, this is rather a "kitchen sink" object.  The compiler
  191. does a good job pruning unused methods, and I don't have any good tools
  192. for examining just which functions I have never used.  The sort is a nice
  193. shell sort I located in PD code, and is fast.
  194.  
  195.      I have been bashing STRA around with some new test code, and it stands
  196. up well.  It doesn't leave any grabage on the heap.  Being in heap space,
  197. it is easy to pass as a parameter between routines - stack friendly.  When I
  198. crank down the heap limits and let the object bump into them, there are
  199. some irregularities I need to track down.
  200.  
  201. \join off
  202.  
  203. \NEW
  204. \CENTER HOLD_object - 3. String & Longint Array - Detail
  205.  
  206. Here is the interface to the HOLD_object:
  207.  
  208. {source \hnrlib\hnrobjs.pas(.HOLD_object)}
  209. \source \hnrlib\hnrobjs.pas(.HOLD_object)
  210.  
  211.  
  212. \NEW
  213. \CENTER FILE_object - 4. Binary File Encapsulation - Detail
  214.  
  215. Here is the interface to the FILE_object:
  216.  
  217. {source \hnrlib\hnrobjs.pas(.FILE_object)}
  218. \source \hnrlib\hnrobjs.pas(.FILE_object)
  219.  
  220. \NEW
  221. \CENTER TFILE_object - 5. TEXT File Encapsulation - Detail
  222.  
  223. Here is the interface to the TFILE_object:
  224.  
  225. {source \hnrlib\hnrobjs.pas(.TFILE_object)}
  226. \source \hnrlib\hnrobjs.pas(.TFILE_object)
  227.  
  228. \NEW
  229. \CENTER OUT_object_0 - 6a. OUTPUT Encapsulation - Detail
  230.  
  231. Here is the interface to the OUT_object (level 0):
  232.  
  233. {source \hnrlib\hnrobjs.pas(.OUT_object_0)}
  234. \source \hnrlib\hnrobjs.pas(.OUT_object_0)
  235.  
  236. \NEW
  237. \CENTER OUT_object_1 - 6b. OUTPUT Encapsulation - Detail
  238.  
  239. Here is the interface to the OUT_object (level 1):
  240.  
  241. {source \hnrlib\hnrobjs.pas(.OUT_object_1)}
  242. \source \hnrlib\hnrobjs.pas(.OUT_object_1)
  243.  
  244.  
  245. \NEW
  246. \CENTER HELP_object - 7. Sectioned TEXT File - Detail
  247.  
  248. Here is the interface to the HELP_object:
  249.  
  250. {source \hnrlib\hnrobjs.pas(.HELP_object)}
  251. \source \hnrlib\hnrobjs.pas(.HELP_object)
  252.  
  253. \NEW
  254. \CENTER DBF_object - 8. DBase DBF File Encapsulation - Detail
  255.  
  256. Here is the interface to the DBF_object:
  257.  
  258. {source \hnrlib\hnrobjs.pas(.DBF_object)}
  259. \source \hnrlib\hnrobjs.pas(.DBF_object)
  260.  
  261.  
  262.      The really ugly code is down one or two levels in DBLKstuf and
  263. XBASstuf, and best that it remain there.  I am not using this heavily
  264. at present, but it tests well and is easy to code with.  The utility
  265. DBPASgen generates a nice shell around the KEYED_DBF_object so that
  266. the interface is a Pascal record structure, and it is not necessary
  267. go into DBASE world.  This topic will get a paper of its own, for
  268. more detail.  It is included here to show that objects can be pretty
  269. high level constructs as well as small building blocks.
  270.  
  271. \NEW
  272. \CENTER BITMAP_object - 9. BitMap 1 - 65000 bits - Detail
  273.  
  274. Here is the interface to the BITMAP_object:
  275.  
  276. {source \hnrlib\bitstuf.pas(.BITMAP_object)}
  277. \source \hnrlib\bitstuf.pas(.BITMAP_object)}
  278.  
  279.